PR progress checklist (to be filled in by reviewers)

• Changes to documentation are appropriate (or tick if not required)
• Changes to tests are appropriate (or tick if not required)
• Reviews completed

What type of PR is this?

A very small fix. I ran into it by searching through our own code-bases after discovering a common error in Salt code.

Primary type

• [build] Changes related to the build system
• [chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
• [ci] Changes to the continuous integration configuration
• [feat] A new feature
• [fix] A bug fix
• [perf] A code change that improves performance
• [refactor] A code change that neither fixes a bug nor adds a feature
• [revert] A change used to revert a previous commit
• [style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)

Secondary type

• [docs] Documentation changes
• [test] Adding missing or correcting existing tests

Does this PR introduce a BREAKING CHANGE?

No.

Describe the changes you're proposing

Replace the defective line - onlyif: {{ grains.os == 'MacOS' }}.

Jinja will generate either True or False with that condition. - onlyif: will attempt to execute this locally on the shell. Unless True exists as an application that can be called in the shell this line will result in the state not getting executed.

I must say, I have seen code like this before. I have written code like this, and recently an AI model suggested code like this. It makes me wonder whether this ever worked by accident. I imagine that if the Jinja templating returned true and false in lower case in the past this code might very well have worked on most Unix systems.

Testing checklist

I do not have a MacOS system, so I cannot test this exact condition. For all I know there exists a True command in the MacOS shell and this code original code functions correctly.

• Included in Kitchen (i.e. under state_top).
• Covered by new/existing tests (e.g. InSpec, Serverspec, etc.).
• Updated the relevant test pillar.

Additional context

I was grepping for this exact kind of mistake that seemed to be somewhat common and came across this instance of the issue.